Concerning "If we block one flow, the socket can no longer be used to communicate with the specific remote IP and fails with EPIPE": Socket Proxy generates new NEFilterFlow for every "pseudo connection"; it seems this means that you get one flow for every "local ip:local port: remote ip: remote port" tuple. In other words, every UDP BSD socket generates as many flows as is the number of "remote ip:remote port" targets it actually contacts. Every such flow can be left in undecided state, you can inspect the traffic etc. But the moment we .drop it, communication with the target becomes impossible from that socket from now on (sendmsg() to it fails with error). Please note traffic to other targets is still working fine. This behaviour is sufficiently weird that most of the apps can not cope with this. I am pretty sure this breaks mDNSResponder process also if you do it to it. Rather than recreating the socket on such error, it simply ignores it. This may lead to weird states like half of dns works because one dns server can be contacted from the socket but half not because the other one was rendered unusable. I have not double checked this mDNSResponder behaviour so please note that I may be wrong (I did analyse it quite a long time ago). But for my test app it behaves like this. Even fixing mDNSResponder does not fix the issue as apps can use their own messaging (dig, libresolv, other 3rd parties) and they will not be ready for this. In general people do not really seem to handle weird errors of UDP sendmsg. IMO for selective filtering of UDP, Socket Filter is not a feasible approach.